1. Field of the Invention
The present invention relates generally to automated troubleshooting, and relates more specifically to applying probability distribution models to improve automated troubleshooting.
2. Introduction
The last quarter-century has been marked by an explosion of consumer electronics with vary levels of complexity. These consumer electronics occasionally fail to function as expected, leaving the consumer to either attempt to fix it himself using a printed or on-line manual, hire a professional to fix it, or call technical support. Included in these consumer electronics are in-home services such DSL routers, DSL connections, and IPTV receivers. Fortunately, these failures are becoming less frequent with improvements in manufacturing and technology. Unfortunately, as a result, consumers have little experience troubleshooting, and generally require assistance to restore their connection. Since devices like DSL modems or cable modems provide Internet connectivity, a failed modem precludes a user from obtaining on-line support. As a result, many consumers resort to calling the technical support department. Technical support calls are expensive and potentially inconsistent for service providers due to human costs, training, equipment, varying skill levels of the technicians, etc. Many Internet service providers therefore desire to provide as much support as possible using an automated interactive voice response (IVR) system.
One conventional solution to this problem is to employ a conventional simple IVR system to initially answer support calls. Simple IVRs ask for information required to route the call to the appropriate operator skill-set, for example, dial-up or DSL connections, or Windows, Mac, or Linux platforms. Simple IVRs may also ask callers to choose from a fixed list of options to self-classify their problem. Some simple IVRs play tips while a user is on hold waiting for a technician. The tips may help some fraction of callers to restore connectivity. These solutions may not adequately address the cost or consistency issues.
More advanced conventional IVRs attempt to engage in a conversation to actually fix the caller's connection. These systems ask questions such as “What color is the network light?” and give pre-prepared instructions based on user responses such as “Now, try switching the DSL router off.” When the caller responds, automated speech recognition (ASR) is used to convert the caller's speech to text. ASR converts speech to text in varying degrees of reliability and is dependent on many external factors. Consequently, text converted by ASR will contain errors. The dialog manager can never know for sure what the user actually said. The IVR may also run a network test, for example to ping the caller's device or to determine if there are any outages reported in the caller's area. The results from the network tests may also be unreliable and may contain errors.
As the dialog progresses, conventional systems maintain a belief about the state of the product or service. Some belief states may include whether it is on or off, failed, working correctly, etc. The IVR cannot observe the product directly or accurately; all information about the product state is derived from the ASR and network test results. Since these inputs may contain errors, the IVR's belief about the product state may be incorrect.
The problem with conventional solutions is that even a single incorrect belief may lead to failed dialogs and low customer satisfaction. For example, if the system believes a DSL router is working when actually it is not, it may end the conversation prematurely. Conventional systems have a number of ad hoc techniques which attempt to reduce the chances of forming an incorrect belief, such as using thresholds on ASR confidence scores and confirmations like “I heard you say ‘XYZ’ is that right?” The problem with these approaches is that they lengthen dialogs, which leads to user frustration. The core problem is that conventional IVR systems can't cope with the ambiguity introduced by errors in the speech recognition and network test inputs. The root cause of this failure to cope is that conventional systems maintain a single guess for the state of the product or service, i.e. conventional systems employ Boolean logic for guessing the state of the product or service. Accordingly, what is needed in the art is a way to way to troubleshoot broken systems by maintaining multiple guess states over time for the state of the product or service.